以公司遇到的情境為例，隨著公司發展了一段歷史，並且旗下擁有的品牌與服務也越來越多，可惜的是在每個服務幾乎都是獨立擁有自己的系統，也就是說即便都掛在同個集團名下，但實際使用時卻需要重複註冊測一次。用戶可能會覺得說：「奇怪，記得這家也是你們公司的，為什麼我還要重新輸入一次這些基本資料呢。」這類的情況仍然存在尚未解決。
面對這種情況也另外衍生了一個問題，在不同服務中都提供了不同商品的優惠，比起現金折扣，公司可能更希望是回饋點數的方式，引導顧客使用點數在公司的其他服務上，創造雙重銷售的效果，另外在顧客持有點數的情況下，留住回頭客的機會也會大許多。這與 Uber 這類服務時常贈送折價券，來引誘用戶使用他們平台的服務，都能達到類似的效果。
為了達到利用點數創造顧客回流的效果，以現行不共通的資料，每個平台可能都各自擁有自己的點數或是折價券，導致顧客可以應用這些回饋的選擇變少，並局限於取得點數的該平台使用，十分可惜。
要解決這種跨平台登入並整合資料的問題，我們可以透過單點登入來解決，就如同我們可以在各種網站中登入 Google 來讀取我們的個人資料。
圖片來源 - https://www.netfriends.com/blog-posts/leveraging-single-sign-on-sso-to-protect-your-business
單點登入（SSO，全名 Single Sign-On）是一種身份驗證技術，讓使用者只需要進行一次登錄，就能夠在多個系統或應用程式之間無縫切換，而無需每次都重新登入。這不僅簡化了用戶的登入過程，也不必重複註冊多個帳號，單點登入常用的機制也能增強系統的安全性。
常見的 SSO 協議：
在現今技術已經相對成熟的時代，許多解決方案已經成為業界標準，我們不再需要從頭開始開發各種協議，尤其在這類資安議題更是企業不可忽視的一環，若在安全中有任何微小疏忽，都可能帶來嚴重的後果。選擇經過市場與時間驗證的成熟應用，不僅能夠加快部署進度，還能減少維護人力，從而降低整體運營成本，也相對安全。
然而，面對市面上眾多的解決方案，如何選出最符合企業需求的應用，並考量每種方案的優劣勢，成為一個關鍵的決策問題。
對於企業來說，自行部署解決方案能夠讓企業完全掌握服務的運作，並在部署過程中進行高度自定義，更貼合維運架構上的環境與場景。然而，這種方案往往需要更多的技術資源和時間來進行微調與維護。雖然自行部署帶來了更大的控制權，但企業也需要擁有足夠的技術能力來管理與維護這些系統。
另一方面，選擇 SaaS（Software as a Service）服務，則能夠讓企業專注於核心業務，因為這些服務通常已經在雲端架設好，並且提供各種第三方應用的快速整合功能。SaaS 服務雖然方便且需要較少的維護人力，但相對的費用也較高，並且企業對於系統的完整控制權會比較有限，功能上依賴服務提供商。因此，選擇 SaaS 或自行部署，沒有絕對的對錯，全看企業的需求以及資源配置而定。
以當時我們在比較 IdentityServer 和 Keycloak 為例，這兩個方案在市場上都有一定的口碑，各自擁有不同的優勢與特色。
IdentityServer：
IdentityServer 是一個半開源的身份驗證和授權框架，特別適合需要高自定義和微調的場景。它基於 .NET 平台，與 Microsoft 相關技術有良好的兼容性，我們還能在官方文件中看到以 IdentityServer 為範例來實現身份驗證服務，對於已經使用 .NET 平台的企業來說是個不錯的選擇。IdentityServer 的彈性很大，並以程式碼實現功能為主，這意味著企業需要擁有較強的技術能力來維護與管理該系統，並且在部署過程中可能需要花費較多的時間與精力，雖說是開源，但在企業需要使用的附加功能等等需要與官方購買許可證。
Keycloak：
Keycloak 是另一個強大的開源身份和訪問管理解決方案，它提供了現成的企業級功能，並且對於企業的部署需求有很好的支持。Keycloak 支持多種協議，如 OAuth2、OpenID Connect 和 SAML，並且有內建的單點登錄（SSO）和社群平台登錄整合功能。與 IdentityServer 相比，Keycloak 的上手難度較低，並且提供了直觀的管理介面。它的彈性較高，但自定義選項可能相對少一些，對於需要快速上線且不需要大量客制化的企業來說，是個理想的選擇。
我們最後偏好將身份驗證服務架設於地端，而不必仰賴其它第三方服務的穩定性，經過許多的討論與嘗試，我們最終選擇可以讓我們高度自定義功能的 IdentityServer，其中一點也是因為公司中的 .NET 人力非常多。
當時在討論使用哪一款解決方案
為了在公司內實現員工的身份認證，我們計畫在 Backstage 中引入 SSO 功能。公司架構的不斷發展，Backstage 將會包含不同平台的微服務，這些微服務同樣需要身份驗證功能。此外，公司本身已有許多系統，這使得實施 SSO 成為必要。與上面提到的面對顧客的角度不同，Backstage 要使用的 SSO 版本屬於面對內部員工的。
在 Backstage 中，使用者登入必須與一個實體對應。若要手動建立數百個使用者實體，這將是一項極為繁瑣的工作。透過 Backstage 與 Active Directory（AD）的同步，我們可以自動從 AD 的員工清單中建立使用者實體，再結合 OIDC（OpenID Connect）協議實現 SSO 架構，通過映射回傳的 mail 屬性自動完成登入。
我們從社群中的其他實作案例中獲得了許多經驗。例如一家外國房地產公司的 IT 團隊，開發了一個能個透過 Ldap 與 AD 直接驗證的插件，來實現 Backstage 的身份驗證。透過直接針對 Backstage 開發的插件，讓他們能夠直接從 AD 驗證使用者身份，省去了額外架設身份服務的功夫。
此外，另一個比較常見的實作方式是透過 Keycloak 部署身份驗證服務，再與 Backstage 進行整合，多數追求能以最小成本完成這件事情，需要快速部署與後續能穩定使用單純需求。
針對公司的具體情況，儘管我們考慮了 Keycloak 能快速解決問題的優勢，但最終決定依賴 AD 進行身份驗證，因為現行系統已經大量依賴 AD 作為主要的員工資料來源。使用 AD 進行可以有效利用現有資源，也降低系統整合的複雜性。因此，雖然 Keycloak 提供了 Ldap 串接的選項，但我們決定選擇更符合公司現行架構的方案。
我們選擇使用 IdentityServer，並與公司現有的 OTP 系統進行整合，以加強身份驗證的安全性 (一部分是因為公司政策及現存的系統架構)。通過 IdentityServer，我們可以自行定義身份驗證流程，並進一步擴展 OIDC 驗證流程與 OTP 結合。
在接下來的三篇專題文章中，我們將圍繞如何在公司內部實現 SSO，並結合 Backstage 的過程，深入探討每一個重要環節。從公司面臨的實際問題出發，逐步介紹從基礎架構與實作細節的過程。我們將依次探討 AD 的串接、OIDC 的基礎範本，以及 Backstage 插件架構的新舊遷移過程。為了讓讀者更好地理解實作過程，每個文章會稍微補充 AD 和 OIDC 的背景知識。
在第一篇文章中，我們將討論如何將公司現有的 AD 與 Backstage 進行整合，實現員工資訊的自動化同步。這篇文章會稍微介紹 AD 的架設方法，並建議先在虛擬機環境中實際架設進行測試。
第二篇文章將聚焦於 OIDC 的基礎架設。我們會分享一個成功的實作案例，展示如何通過 Backstage 的 OIDC 插件來實現身份驗證。在這篇文章由於使用到舊版的插件，我們將以概念展示為主，略過詳細的實作步驟，讀者能先理解整體流程。
最後一篇文章將深入探討如何將舊版的身份驗證插件遷移至新版 Backstage 的架構。演示插件開發的過程，並解決舊版與新版插件之間的問題，最後再使用 IdentityServer 的 OIDC 驗證範本，實現完整整合 SSO 的身份驗證功能。
在開發 Backstage 的過程中，經常會面臨現有架構與新功能需求之間的抉擇，這些抉擇會時常重現。透過本系列文章的案例分享，我們希望能幫助讀者預見並解決類似的問題，為團隊提供更多參考與指引。
https://www.netfriends.com/blog-posts/leveraging-single-sign-on-sso-to-protect-your-business
https://www.linkedin.com/pulse/hosted-vs-self-hosted-identity-access-management-solution-
iThome鐵人賽
看影片追技術